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Abstract 


This memo defines a mechanism whereby a SMTP client can request, when 
transmitting a message to a SMTP server, that the server deliver the 
message within a prescribed period of time. A client making such a 
request also specifies the message handling which is to occur if the 
message cannot be delivered within the specified time period: either 
the message is to be returned as undeliverable with no further 
processing, or a "delayed" delivery status notification (DSN) [6] is 
to be issued. 


This extension should not be viewed as a vehicle for requesting 
"priority" processing. A receiving SMTP server may assign whatever 
processing priority it wishes to a message transmitted with a Deliver 
By request. A Deliver By request serves to express a message’s 
urgency and to provide an additional degree of determinancy in its 
processing. An indication of an urgent message’s status within a 
given time period may be requested and will be honored. Moreover, 
the message may be withdrawn if not delivered within that time 
period. 


A typical usage of this mechanism is to prevent delivery of a message 
beyond some future time of significance to the sender or recipient 
but not known by the MTAs handling the message. For instance, the 
sender may know that the message will be delivered as a page but does 
not consider the message to be sufficiently important as to warrant 
paging the recipient after business hours. In that case, the message 
could be marked such that delivery attempts are not made beyond 
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17:00. Another common usage arises when a sender wishes to be 
alerted to delivery delays. In this case, the sender can mark a 
message such that if it is not delivered within, say, 30 minutes, a 
"delayed" DSN is generated but delivery attempts are nonetheless 
continued. In this case the sender has been allowed to express a 
preference for when they would like to learn of delivery problems. 


1. Definitions 


Throughout this document, the term "deliver" is taken to mean the act 
of transmitting a message to its "final" destination by a message 
transport agent (MTA). Usually, but not always, this means storing 
or otherwise handing off the message to the recipient’s mailbox. 
Thus, an MTA which accepts a message to be delivered within a 
specified time period is agreeing to store or handoff the message to 
the recipient’s mailbox within the specified time period. Outside 
the scope of the term "deliver" are any user-specified actions which 
might take place after the MTA stores or hands off the message; e.g., 
user-programmed filters which, often unbeknownst to the MTA, resend 
the message to some other location. 


The key words "MUST", "MUST NOT", "SHOULD" and "SHOULD NOT" in this 
document are to be interpreted as described in RFC 2119 [7]. 


2. Framework for the Deliver By SMTP service extension 


The Deliver By SMTP service extension uses the SMTP service extension 
mechanism described in [4]. The following SMTP service extension is 
therefore defined: 


(1) The name of the SMTP service extension is "Deliver By". 


(2) The EHLO keyword value associated with this service extension is 
"DELIVERBY". 


(3) One optional parameter is allowed with this EHLO keyword value. 
The optional parameter, when supplied, is a comma separated list 
of options. Only one option, a min-by-time, is specified in 
this document. Future documents may extend this specification 
by specifying additional options. The min-by-time is a fixed 
integer indicating the fixed minimum by-time that the server 
will accept when a by-mode of "R" is specified as per Section 4. 


The syntax of the optional parameter is as follows, using the 
augmented BNF notation of RFC 2234 [2]: 
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deliverby-param = min-by-time *( ’,’ extension-token ) 

min-by-time [1*9DIGIT] 

extension-token 1*<any CHAR excluding SP, COMMA and all control 
characters (US ASCII 0-31 inclusive) > 

SP = <the space character (ASCII decimal code 32)> 

COMMA <the comma character (ASCII decimal code 44)> 


If the parameter is omitted, no information is conveyed about 
the server’s fixed minimum by-time. 


(4) One optional parameter using the keyword "BY" is added to the 
MAIL FROM command. 


(5) The maximum length of a MAIL FROM command line is increased by 
17 characters by the possible addition of the BY keyword and 
value. 


(6) No additional SMTP verbs are defined by this extension. 
3. The Deliver By SMTP service extension 


A SMTP client wishing to use the Deliver By SMTP service extension 
may issue the EHLO command to start a SMTP session and to determine 
if the SMTP server supports the service extension. If the server 
responds with code 250 to the EHLO command, and the response includes 
the EHLO keyword DELIVERBY, then the Deliver By SMTP service 
extension is supported by the server. 


If a numeric parameter follows the DELIVERBY keyword value of the 
EHLO response then that parameter indicates the minimum value allowed 
for the by-time when a by-mode of "R" is specified with the extended 
MAIL FROM command as described in Section 4. Any attempt by a client 
to specify a by-mode of "R" and a by-time strictly less than this 
limit, min-by-time, will be rejected with a permanent failure (55z) 
reply code. 


A SMTP server that supports the Deliver By SMTP service extension 
will accept the extended version of the MAIL FROM command described 


in Section 4. When supported by the server, a SMTP client may use 
the extended MAIL FROM command (instead of the MAIL FROM command 
described in [1]) to request that the message be delivered within the 


specified time period. The server may then return an appropriate 
error code if it determines that the request cannot be honored. Note 
that this may not be apparent to the server until either presentation 
of the recipient addresses with RCPT TO commands or completion of the 
transfer of the message data with the dot (.) command. As such, the 
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server may send to the client a success response to the MAIL FROM 
command only to later return an error response to the RCPT TO, DATA, 
or dot command. 


4. The extended MAIL FROM command 


The extended MAIL FROM command is issued by a SMTP client when it 
wishes to inform a SMTP server that a message is to be delivered 
within a specified period of time and further what action to take 
should the message prove undeliverable within that time period. The 
extended MAIL FROM command is identical to the MAIL FROM command as 
defined in RFC 821 [1], except that a BY parameter appears after the 
address. 


The complete syntax of this extended command is defined in [4]. The 
esmtp-keyword is "BY" and the syntax for the esmtp-value is given by 
the syntax for by-value shown below. In the augmented BNF of RFC 
2234 [2], the syntax for the BY esmtp-parameter is 


by-parameter "BY="by-value 


by-value = by-time"; "by-mode [by-trace] 

by-time = ["-" / "4"]1*9digit ; a negative or zero value is not 
; allowed with a by-mode of "R" 

by-mode = "N" / "R" ; "Notify" or "Return" 

by-trace Ok bed ; “Trace” 


Note that the BY esmtp-keyword MUST have an associated esmtp-value. 
The by-time is a decimal representation of the number of seconds 
within which the message should be delivered and has the range 


-999,999,999 seconds <= by-time <= +999,999,999 seconds 


and is thus sufficient to represent a time anywhere from 
approximately 31.6 years in the past to 31.6 years in the future. 


As described in Section 4.1, the by-mode indicates the action the 
SMTP server must take should it not be possible to transmit the 
message within by-time seconds. 


Note that by-time is a delta time: the number of seconds within which 
to deliver the message. This delta time does not extend an MTA’s 
normal retention period for undeliverable messages nor is it a 
"deliver after" time. 


A delta time is used so as to prevent problems associated with 
differences in system clocks between clients and servers. Servers in 
receipt of a valid by-parameter are expected to convert the by-time 
into a locale-specific absolute time called the deliver-by-time. 
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This is done by adding the by-time upon receipt to the current 
locale-specific time and thereby arriving at a locale-specific 
absolute time which is by-time seconds in the future or past, 
depending upon the arithmetic sign of by-time. The message is then 
to be delivered by the deliver-by-time. The sending client and 
receiving server should assume the transmission time of the MAIL FROM 
command to be instantaneous. Clearly, it will not be and network 
latency will introduce an error, the nature of which will be to 
extend slightly the effective by-time. The more hops the message 
takes, the more pronounced the effect will be owing to the cumulative 
nature of this latency-induced error. 


In the case of a by-mode of "N", it is possible that by-time may be 
zero or negative. This is not an error and should not be rejected as 
such. It indicates a message for which the deliver-by-time occurred 
—(by-time) seconds in the past. [Here, "—(by-time)" represents the 
arithmetic negation of the by-time value.] Zero and negative values 
are allowed so as to preserve information about any requested 
delivery time information -- information which the delivering MTA may 
wish to include with the delivered message for the benefit of the 
recipient or to show in a DSN or NDN (non delivery notification). 


In the case of a by-mode of "R", a zero or negative by-time is a 
syntax error. In such a case, the SMTP server SHOULD return a 
permanent failure (501) SMTP reply code in response to the extended 


MAIL FROM command. If the SMTP server also supports enhanced error 
codes [8], then an enhanced error code of 5.5.4 SHOULD also be 
returned. 


If the by-time is a valid by-time specification but the SMTP server 
cannot honor or accept it for a server-specific reason, then SMTP 
server SHOULD respond with either a 455 SMTP response if the 
condition is transient or a 555 SMTP response if the condition is 
permanent. In addition, if the SMTP server also supports [8], a 
suitable 4.X.X or 5.X.X enhanced error code SHOULD also be returned. 


4.1. Server behavior upon receipt of the extended MAIL FROM command 


Upon receipt of an extended MAIL FROM command containing a valid BY 
parameter, a SMTP server and associated MTA must handle the message 
in accord with the following subsections, Sections 4.1.1-4.1.5. 
Delivery status notifications generated in response to processing a 
message with a Deliver By request should include both the optional 
Arrival-Date DSN field as well as the new Deliver-By-Date DSN field 
described in Section 5 of this memo. 
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A by-time Note that a message’s by-time does not extend the MTA’s 
normal message retention period: an MTA MAY return a message as 
undeliverable before the deliver-by-time has been reached. 


4.1.1. Successful delivery 


If the message is delivered before deliver-by-time, no special action 
need be taken. If the SMIP server or MTA also supports the Delivery 
Status Notification SMTP service extension [5] and a NOTIFY parameter 
including "SUCCESS" was specified, a "delivered" DSN with appropriate 
status must be returned as per [5]. 


4.1.2. Unsuccessful delivery; deliver-by-time not yet reached 


If deliver-by-time has not yet passed and the message has proved 
undeliverable for temporary reasons, then the SMTP server or MTA 
should continue delivery or relay attempts as per the site’s message 
handling policy. If the MTA’s message retention period is less than 
by-time, the MTA MAY return the message as undeliverable before 
deliver-by-time has been reached. However, the message MUST still be 
handled in accord with Sections 4.1.1-4.1.5. 


If deliver-by-time has not yet passed and the message cannot be 
delivered for permanent reasons, then the SMTP server or MTA MUST 
return a "failed" DSN with an appropriate status for each recipient 
address with either no NOTIFY parameter specified or for which the 
NOTIFY parameter includes "FAILURE". 


4.1.3. Time has expired; deliver-by-time reached or passed 


If the message is not delivered or relayed before deliver-by-time and 
a by-mode of "R" was specified, no further delivery attempts may be 
made for the message. The server or MTA MUST issue a "failed" DSN 
with status 5.4.7, "delivery time expired", for each recipient 
address with either no NOTIFY parameter specified or for which the 
NOTIFY parameter includes "FAILURE". 


If the message is not delivered or relayed before deliver-by-time and 
a by-mode of "N" was specified, the server or MTA should continue 
attempts to deliver or relay the message using the site’s message 
handling policy. In addition, the server or MTA MUST issue a 
"delayed" DSN with status 4.4.7, "delivery time expired", for each 
recipient address with either no NOTIFY parameter specified or for 
which the NOTIFY parameter includes "DELAY". 
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4.1.4. Relaying to another SMTP server 


Sections 4.1.4.1 and 4.1.4.2 below describe when a message with a 
Deliver By request may be relayed to another SMTP server and what 
additional actions, if any, should or must be taken. In addition to 
that discussed in those sections, the following must also be observed 
when relaying is permitted. 


If the message is relayed to a SMTP server that supports the Deliver 
By extension, a new BY parameter MUST be relayed specifying a by-time 
value indicating the number of seconds remaining until deliver-by- 
time. The new by-time value should be computed as close to the time 
the MAIL FROM command is transmitted by the relaying SMTP client as 
is reasonably possible. Note that if deliver-by-time has passed, the 
relayed by-time will be a negative value indicating how may seconds 
has elapsed since delivery-by-time. Such a case -- relay of a 
message for which deliver-by-time has just arrived or passed -- may 
only happen with a message that has a by-mode of "N". 


When a message with a by-trace field with value "T" is relayed, a 
"relayed" DSN SHOULD be generated by the relaying SMTP client for 
each recipient which either did not specify a NOTIFY parameter or the 
NOTIFY parameter does not have the value "NEVER". 


Note that these "relayed" DSNs are generated regardless of whether 
success notifications were explicitly requested with a NOTIFY=SUCCESS 
parameter. Note further that the "relayed" DSNs discussed here are 
not terminal notifications: downstream SMTP servers and MTAs may 
still support [5] and as such additional notifications may still 
result. 


4.1.4.1. Relaying a message with a by-mode of "R" 


A message for which a by-mode of "R" was specified MUST NOT be 
relayed to a SMTP server which does not support the Deliver By SMTP 
service extension. Moreover, the server to which it is relayed MUST 
NOT have a fixed minimum by-time which is greater than the time 
remaining in which the message is to be delivered. The fixed minimum 
by-time is expressed by the optional deliverby-param discussed in 
Section 2. 


If the message requires relaying in order to be delivered yet cannot 
be relayed, then the message is deemed to be undeliverable for 
permanent reasons and Section 4.1.2 should be applied. 
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4.1.4.2. Relaying a message with a by-mode of "N" 


A message with a by-mode of "N" may be relayed to another server 
regardless of whether or not the SMTP server to which it is relayed 
supports the Deliver By extension. 


If the message is relayed before deliver-by-time to a SMTP server 
that does not support the Deliver By extension, then the relaying 
SMTP client MUST issue a "relayed" DSN for each recipient which 
either did not specify a NOTIFY parameter or the NOTIFY parameter 
does not have the value "NEVER". Further, if the SMTP server being 
relayed to supports the Delivery Status Notification SMTP service 
extension [5] then for each recipient: if no NOTIFY parameter was 
supplied, "NOTIFY=FAILURE, DELAY" SHOULD be requested; if a NOTIFY 
parameter was specified and does not have the value "NEVER", "DELAY" 
SHOULD be added to the list of notify-list-element values if not 
already present. Note that this explicitly overrides the "MUST NOT" 
wording of Section 6.2.1(c) of [5]. 


4.1.5. Relaying to a foreign mail system 


If the foreign mail system supports semantics similar to the Deliver 
By SMTP service extension described in this memo, then convey the 
Deliver By request to that system. Otherwise, relay the message as 
if relaying to a SMTP server which does not support the Deliver By 
extension. 


5. Delivery status notifications and extension 


The format of delivery status notifications (DSNs) is specified in 
[6]. DSNs generated in response to a Deliver By request should 
include an Arrival-Date DSN field. This memo also extends the per- 
message-fields of [6] to include a new DSN field, Deliver-By-Date, 
indicating the deliver-by-time as computed by the MTA or SMTP server 
generating the DSN. In the augmented BNF of RFC 822 [2], per- 
message-fields is therefore extended as follows: 


per-message-fields = 
[ original-envelope-id-field CRLF ] 
reporting-mta-field CRLF 
[ dsn-gateway-field CRLF ] 
[ received-from-mta-field CRLF ] 
[ arrival-date-field CRLF ] 
[ deliver-by-date-field CRLF ] 
*( extension-field CRLF ) 
deliver-by-date-field = "Deliver-by-date" ":" date-time 
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where date-time is a RFC 822 [2] date-time field as ammended by RFC 
1123. p341- 


6. Examples 


In the following sample SMTP dialog, the SMTP client requests that a 
message from <eljefe@bigbiz.com> be delivered to 
<topbanana@other.com> within 2 minutes (120 seconds) and returned 
otherwise. This request takes the form of a BY parameter on the MAIL 
FROM line of "BY=120;R" as shown below: 


220 acme.net SMTP server here 

EHLO bigbiz.com 

250-acme.net 

250 DELIVERBY 

MATL FROM:<eljefe@bigbiz.com> BY=120;R 
250 <eljefe@bigbiz.com> sender ok 

RCPT TO:<topbanana@other.com> 

250 <topbanana@wherever.com> recipient ok 


NANANNAN 


Suppose now that the receiving SMTP server in the above example needs 
to relay the message to another SMTP server, mail.other.com. Owing 
to the original by-mode of "R", the message may only be relayed to 
another SMTP server which supports the Deliver By extension (Section 
4.1.4). Further, when relaying the message, the Deliver By request 
must be relayed. With this in mind, consider the following SMTP 
dialog: 


220 mail.other.com ESMTP server at your service 
EHLO acme.net 

250-mail.other.com 

250 DELIVERBY 240 

QUIT 


ANNAN 


In the above dialog, the relaying SMTP server, acme.net, connects to 


mail.other.com and issues an EHLO command. It then learns that the 
Deliver By extension is supported but that the minimum by-time for a 
by-mode of "R" is 4 minutes (240 seconds). This value exceeds the 


message’s original by-time and therefore necessarily exceeds the 
remaining by-time. The relaying SMTP server thus ends the SMTP 
session after which it must either attempt to follow any other MX 
records or, if there are no more MX records to follow, must return 


the message as undeliverable. Similar behavior would result if the 
EHLO command was met with an error or did not include the DELIVERBY 
keyword. 


Consider instead, the relaying SMTP session: 
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220 mail.other.com ESMTP server at your service 
EHLO acme.net 

250-mail.other.com 

250 DELIVERBY 30 

MAIL FROM:<eljefe@bigbiz.com> BY=98;R 

250 <eljefe@bigbiz.com> Sender okay 

RCPT TO:<topbanana@other.com> 

250 <topbanana@wherever.com> Recipient okay 


NANANNAN 


In the above, the relaying SMTP client relays the BY parameter with 
the by-mode preserved and the by-time computed to be the remaining 
number of seconds at the approximate time that the MAIL FROM command 
was transmitted from the relaying SMTP client (acme.net) to the 
receiving SMTP server (mail.other.com). In this example, 22 seconds 
have elapsed since acme.net received the MAIL FROM line from the 
original sending client and relayed the Deliver By request to 
mail.other.com. 


7. MX based relaying considerations 


Sites which wish to use the Deliver By SMTP service extension and 
which direct their mail via MX records [9] need to ensure that all of 
their MX hosts -- hosts to which their mail is directed by MX records 
-- support the Deliver By extension. SMTP clients which support 
Deliver By SHOULD NOT attempt multiple MX hosts looking for one which 
supports Deliver By. 


MX hosts should pay careful attention to the min-by-time value they 
present in response to EHLO commands. It is not practical for an MX 
host to present a value which either (1) is substantially different 
from that which can be handled by the destination host to which it 
relays, or (2) doesn’t recognize normal delivery latencies introduced 
when the MX host relays mail to the destination host. 


8. Security Considerations 


Implemention of Deliver By allows tracing of a mail transport system. 
The by-trace field "T" explicitly requests that a trace be generated. 
Moreover, even when the by-trace field is not used, a crude trace may 
be generated by entering a series of messages into the transport 
system, each with successively increasing by-time values; e.g., 
"BY=0;R", "BY=1;R", "BY=2;R". Probing, and in some cases tracing, can 
be accomplished through other means: querying the visible SMTP 
servers, investigating Received: header lines in bounced messages, 
and using utilities such as "traceroute". 
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9:5 


10. 


Other Considerations 


SMTP servers which support the Deliver By SMTP service extension as 
well as their associated MTAs are not required to assign any special 
processing priority to messages with Deliver By requests. Of course, 
some SMTP servers and MTAs may do so if they desire. Moreover, 
delivery status notifications generated in response to messages with 
Deliver By requests are not required to receive any special 
processing. Consequently, users of this service should not, in 
general, expect expedited processing of their messages. Moreover, 
just because a message is sent with a "BY=60;R" parameter does not 
guarantee that the sender will learn of a delivery failure within any 
specified time period as the DSN will not necessarily be expedited 
back to sender. 
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13. Full Copyright Statement 
Copyright (C) The Internet Society (2000). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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